【小ネタ】AWSのプロが aws cli を使う方法 (debug オプション)

コンサル部の（キム）テウです。来年からは韓国の人がガンガン採用されて入社される予定なので、これからは下の名前だけで呼ばれることになりました。韓国ですと、金（キム）は多すぎますので（笑）今回は aws cli を使う時に問題が発生して、そこで何が問題だったかを早く把握できる --debug オプションをご紹介させていただきます。

#AWS CLI

#AWS

金泰雨

2019.11.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンサル部の（キム）テウです。

来年からは韓国の人がガンガン採用されて入社するので、これからは下の名前だけで呼ばれることになりました。韓国ですと、金（キム）は多すぎますので（笑）

今回は aws cli を使う時に問題が発生して、そこで何が問題だったかを早く把握できる --debug オプションをご紹介させていただきます。

--debug オプションの使い方

他の cli ツールと一緒で、aws cli も --debug オプションが利用可能です。

$ aws ecr describe-repositories --debug

こんな感じにコマンドの最後に --debug オプションを付けるだけで、下のようなログが見えます。

$ aws s3api create-bucket --bucket aws-cli-sample-bucket-twkiiim --region=ap-northeast-1 --create-bucket-configuration LocationConstraint=ap-northeast-1 --debug

debug-mode-log-example

トラブルシューティングが必要ないろんなパターン例

例えば、以下のように private subnet の EC2 インスタンスから S3 バケットに接続するとします。

private-subnet-to-s3

そういう時に private subnet に紐づいている Route Table にターゲットとして NAT Gateway が登録されてあったり、VPC Endpoint がその private subnet にアタッチされたりする必要がありますよね。

private-subnet-to-s3-with-vpc-endpoint

上のように VPC Endpoint がVPCにアタッチされて、Route Table にも設定されてあった場合でも VPC Endpoint の Policy 周りの設定等が間違ったりする場合もあります。NAT Gateway の場合でも、複雑な構成ですと、間違って他の Route Table に NAT Gateway を連携するなど、いろんなミスパターンがあると思います。

そういう時にその EC2 インスタンスに直接接続して、トラブルシューティングをすることも多いですよね。ですが、そもそも Network 構成が間違っているのであれば、aws cli を使っても何もできずにタイムアウトされてしまいます。

そこで！！

AWSプロの皆さんは、この --debug オプション、きっと使っていらっしゃいますよね？

もし、まだ使ったことがなかったとしても大丈夫です。次の章で、AWSプロのトラブルシューティングの方法を一緒に学んでみましょう！

AWSプロのトラブルシューティング方法

例えば、以下の構成図の通り、private subnet で VPC Endpoint が紐づいてて、そこで ECR DKR と ECR API の VPC Endpoint がアタッチされたとします。

private-subnet-to-ecr-with-vpc-endpoint

でも何故か EC2 から ECR に繋がっていない状態です。踏み台サーバ経由で、直接 EC2 に接続して、下のコマンドを実行してみます。

$ aws ecr describe-repositories

なかなかレスポンスが来ないです。ずーっと待っていても、こうなって何も分からないですね。 no-response-from-cli

その時、直感的に「あ、おそらく Security Group の問題では？」と思われますか？素晴らしいです。

ですが、そこからもう一歩進んで、この --debug オプションを付けることで、何が本当の問題だったかをすぐ把握することも出来ます。

$ aws ecr describe-repositories --debug

結果は下のように何かがすぐ出力されます。 aws-cli-debug-option-result

一番下のログを見ると、HTTPS コネクションが出来なかったことをすぐ分かります。

そうですね。ECR API は Interface 系の Endpoint なので、Security Group を Endpoint に連携して利用するのサービスですが、ECR API は HTTPS で通信をするので、443ポートを解放する必要がありました。443ポートが解放されていなかったため、通信が出来なかったということです。

443ポートを解放したら、すぐ正常に動きました。

最後に

debug オプションは、当たり前なことだと思う一方で、普段から使いこなせるように練習をしておかないと、トラブルシューティング時にハマってしまいますよね。実は、私も作業時に、この debug オプションが身に付いてなかったので結構ハマりましたが、弊社の城岸から「--debugオプションつけてみてね」って言われて助かりました。（私が1時間半ハマっていてもなかなか分からなかったことを、城岸は10秒だけで解決したのです。。）

以上、--debug オプションはこれからもガンガン使いましょう！！という記事でした。